Bringing the MBONE Home: Experiences with Internal Use of Multicast-Based Conferencing Tools

Some authorities feel that increasing amounts of traffic, rising popularity of multicastbased conferencing tools, and increasing availability of multicast routing technology are signals of impending doom for the Internet’s Multicast Backbone (MBONE). However, they are also clear signals that there is a very real demand for the services of which they are a result: real-time, multipoint, multimedia interaction between network users. Whether or not the utility of the MBONE itself is drawing to a close, it is a simple step to draw parallels between the demands of users on the Internet and the demands of users on a large corporate network, and to see that the same tools in use on the MBONE can be used to provide an important service in a corporate network environment. This paper will describe the implementation of a widely distributed conferencing system based on IP multicast networking and freely available conferencing tools. It will describe the network topology and routing technology employed, the scope of the system, some challenges encountered in implementing the system, the tools used in the implementation, real examples of the use of the system, future plans for the system and an exploration of some potential pitfalls of the system. The information presented in this paper is based on experiences gained in deploying the system on the Engineering departmental networks at Cisco Systems. Opinions expressed in this paper are those of the author, and do not necessarily reflect the opinions of Cisco Systems. IP Multicast Networking The features of IP multicast [1] which make it indispensable as a transport for conferencing applications traffic on the Internet make it equally indispensable on a corporate network: use of multicast enables wide distribution of the traffic over backbone networks with a minimum of replication; large numbers of hosts on a single network are able to simultaneously receive a single stream of multicast traffic; judicious configuration and use of multicast routers enables networks with no participants to not receive the traffic at all. What Is IP Multicast? IP multicast networking uses a method of addressing IP packets so that their destination is a ‘‘group’’ of hosts rather than a single host or a broadcast. A group can contain zero or more hosts, and hosts can dynamically join or leave a group at any time. These groups are addressed using class D IP addresses, which have the four high-order bits set to ‘‘1110’’. In dotted decimal notation this means the range of group addresses is from 224.0.0.0 to 239.255.255.255. Using these group addresses it is possible to deliver data to multiple hosts on a network with a single stream of data for the entire group, rather than duplicating the data for each host that ‘‘wants’’ to receive it. 256 addresses in the lowrange of the class D address space are reserved. For instance, 224.0.0.1 is the group address for ‘‘all’’ IP hosts (which in effect is all multicast capable hosts on a single network); 224.0.0.2 is the group address for all multicast routers. Using IP multicast is similar to using IP broadcast in that it is a method of contacting multiple hosts simultaneously, and therefore provides an efficient method of delivering data to many hosts. Unlike broadcast traffic on a network, hosts are not required to ‘‘listen’’ to multicast traffic since the joining of a group is voluntary. Also unlike broadcast traffic (in most cases) multicast traffic can easily be routed between multiple networks. For the purposes of implementing the ability to participate in multicast-based conferencing, a host should have full (level 2) support of IP multicast, which includes the ability to send and receive multicast traffic, and the ability to join and leave host groups. These abilities are accomplished using the Internet Group Management Protocol (IGMP) and extensions to a host’s network interface code. The networking extensions are required to allow a host to receive data addressed to any host-groups to which it is joined, rather than data addressed only to that host or to a broadcast address. The IGMP extensions allow the host to inform any multicast routers on its network of the host’s membership in any host groups. 1995 LISA IX – September 17-22, 1995 – Monterey, CA 103 Bringing the MBONE Home: Experiences with ... Mott Routing IP Multicast Traffic The most commonly used methods for routing IP multicast traffic are Distance Vector Multicast Routing Protocol [2] (DVMRP) and Protocol Independent Multicast [3] (PIM) routing. Another method available is Multicast OSPF [4] (MOSPF). Of these routing methods DVMRP is probably the most widely used since it has been available for the longest time, and can be run using the multicast routing daemon (mrouted) on a large number of UNIX platforms. Various router vendors have implemented one or more of these multicast routing methods. Most multicast routing methods include mechanisms for ‘‘tunneling’’ multi-cast traffic through non-multicast-capable routers to allow seemingly continuous multicast connectivity across segments of networks where multicast traffic is not supported. Tunneling is usually accomplished by encapsulating multicast traffic inside of regular IP unicast packets to allow it to be routed. Multicast on our Engineering Networks Cisco Engineering’s use of multicast networking in our production networks was driven by a need to test our multicast routing code. One of the easiest ways to perform this testing was to use existing applications that generated large amounts of multicast data. Since the MBONE was already being used to multicast audio, video, whiteboard and other data, and since tools for sending and receiving this sort of traffic had been developed and used on the MBONE, it was easy to decide that building an internal equivalent of the MBONE would be a good beginning for our testing. We started to install multicast capability on a subset of our desktop workstations, and receiving broadcasts from the MBONE. The number of networks which included multicast support started out quite small, but as more people became aware of the existence of the internal availability of the MBONE, the demand to deploy multicast routing capability and conferencing tools widely became overwhelmingly apparent. Deploying Multicast Routing Like most MBONE users our original routing configuration was based primarily on DVMRP routers using the ‘mrouted’ program, and connected to each other via DVMRP tunnels. The DVMRP routers used were Sun machines. We also used a DVMRP tunnel to our Internet Service Provider as our connection to the MBONE, as well as DVMRP tunnels interconnecting the networks where we wanted to deliver multicast traffic. As development of Cisco’s implementation of PIM routing continued, we started using PIM routers to support various networks. We replaced many of the DVMRP routers which were supporting test networks, and added test networks using PIM support. We gradually deployed PIM routers on a subset of production nets, but maintained DVMRP connection to Internet. As our comfort level with multicast routing grew, we deployed it on more of our production networks until it became a ‘default’ feature on Engineering networks in our environment. When our Internet Service Provider was ready, we finally moved to all PIM routing, including our Internet connection